code review: gerrit实战

gerrit是git的超集，实操过程中会遇到很多问题，解决起来学习曲线比较陡峭。因此本节整理了一下常见问题，给出解决方案。过程中会涉及一些原理。

gerrit做code review的原理：当开发者提交一个change时，相当于在gerrit上的临时分支提交代码。比如在master修改后提交change等待review，实际上代码提交到了refs/for/master分支上。review完submit的时候，代码才会真正提交到master上。

gerrit的gitlab插件会将gitlab作为gerrit的slave，每隔几秒就把最新的真实分支的代码提交到gitlab上。当有人绕过gerrit向gitlab提交代码，在插件工作时，会认为两个仓库不同步，从而不能合并。 如果要解决这个问题，我们需要把gitlab最新的改动手动同步到gerrit上。

在本地执行：

change id是gerrit change的唯一标识。每一个change id代表一个code review的请求。在向gerrit push代码时，我们经常会遇到missing Change-Id in message footer的报错。主要有两个原因：

每次git commit的时候git会自动执行.git/hooks/commit-msg脚本，为commit添加change id。这个.git/hooks/commit-msg脚本是在clone仓库的时候一起下载下来的。

如果没有使用带hook的地址clone代码，push时会报错：

如果想正确提交代码，需要根据报错提示执行操作：

比如pull+自动merge的时候git hook加上了change id，然后又自动追加了merge冲突的文件名，这样change id不在最后一行，gerrit识别不出来会报错。

具体报错信息如下：

如果想正确提交代码，需要根据报错提示执行操作：

经常会出现这样的情况：在pull代码之后，没有直接提交，直接基于pull的结果进行了修改。最终向gerrit提交代码时发现中间有一个commit没有change id。

如下图所示，在这个例子中一共有三个commit需要提交，分别是ea24f1d，4f99a0e，37958d1。其中4f99a0e没有change id。

处理这样的情况，一般有两种方式：

我们需要check到没有change id的commit，添加change id后手动提交。我们先提交ea24f1d和4f99a0e两个commit。

看一下merge这个change的最后一个commit id，我们发现已经不是原来的4f99a0e，已经变成了2b9dbee。

而第三次提交37958d1还是基于4f99a0e，而不是基于2b9dbee。我们需要基于2b9dbee重做第三次提交。

我们可以批量把commit rebase到一个commit。rebase多个commit的操作见3.2节讲解。

假设现在完成了一个需求，准备提交code review:

在push之前突然发现了一个bug。如果正常提交，在gerrit上就会有两个change。reviewer在看第一个change的时候，不知道哪些是第二个已经修复的bug，哪些是没修复的，对比起来很麻烦。 我们提倡同一个需求、相互依赖的两个改动尽量放在一个change里。方便reviewer review，也会减少一些不必要的冲突。 第二个commit我们用--amend参数来修改上一个commit：

这样就会作为一个change提交了

有时当我们git pull/git merge的时候，解决冲突后，会自动生成没有加change id的commit，夹在多个commit中间（见2.3节的情况）；或者commit忘记加--amend的时候，在提交gerrit的时候会变成多个changes。我们可以用rebase操作合并多个commit。

假如现在有三个commit(19e38cb, 4bea9f9, 710b142)我们希望合并为一个commit:

可以用rebase批量合并最近3个commit

把pick修改为s(squash)

然后保存。本地会由上至下重做3个commit。

成功合并：

开发者正常提交了一个change到gerrit，reviewer看过之后觉得有些地方需要修改，这个时候开发者需要修完之后继续提交新的patchset到原来的change里，方便reviewer对比。 主要分三种情况： 1）修改的change是最后一个change，后面再没有修改了 2）修改的change后面还有其他change，改完需要把这个修改同步到后面的change上，这种情况比较复杂 3）修改的change后面还有其他change，改完需要把这个修改同步到后面的change上，但最新的改动和后面的change有冲突，复杂程度MAX

假设现在正常提交了一个change：

在gerrit上能看到这个新的change。我们可以点击右下角update change获取修改change的提示。

按照提示操作：

可以看到提交了新的patchset

可以点击对比，查看第二次修改的内容

假设我们连续提交了三个change，第一个有bug。

我们按照4.1节的操作，修复这个bug。

会发现剩下的change2, change3旁边出现了神奇的绿色字体(Indirect ancestor)，点击进入change2也会看到神奇的红色字体(Not current)。

如果这时合并了change1，会发现change2冲突了，即使change1和change2没有修改同一行代码。这是因为对于change1 patch2修改的代码行，已经合并的change1 patch2的代码和change2上的代码是不一样的。我们可以在合并change1之前把change2和change3调整为基于change1的patch2，否则合并后解决冲突就请参照4.3吧。

我们可以进入change2页面，点击右上角rebase，大功告成。

同样处理change3：

只要change1的patch2和change2的patch1同时对一行做了修改，gerrit会认为是冲突的。

我们需要分别在change2和change3上rebase change1最新的改动，在rebase过程中解决冲突。 先解决change2的冲突：

第二次提交的冲突已经解决：

我们用同样的方法解决change3的冲突，不过这次是需要change3上应用change2。

去gerrit的页面上看，第三次提交也不冲突了。

4.2节中我们主要讨论了对parent change改动引起的冲突，本节我们主要讨论多人改动引起的冲突。

当两个人同时基于一个分支进行修改，提交了两个冲突的change。

不管有没有合并，我们都可以用同样的方式解决冲突。

成功解决冲突：